One form of software testing involves running software under test using a target computing device that is compatible with the instruction set presented by the target device. In such a scenario, both the software under test and the target hardware may be under development. Accordingly, issues related to how the software under test interacts with the hardware may be under scrutiny. In such an environment, a hardware/software development system having a target device or emulator is typically used. It is common to use breakpoints in such an environment to check the progress of software execution by performing activities such as examining operands for a given address or other registers to determine the state of the target machine during the software execution. Breakpoints may generally be programmed into one part of the development system such that when an instruction pointer address matches the breakpoint, the development system halts execution of the software under test.
One typical development system may have one or more hardware devices which can detect the breakpoint address and halt execution of the software under test. In some instances, a software only solution to the hardware address detection mechanism is desired. However, such software only detection schemes can be very slow because the software program may single step through the software under test, generate an exception at every step, communicate with debugger software, determine if the breakpoint has been reached, and then execute the next step. Such a development system does not let the target hardware and software run at full speed.
Breakpoints based on data values are used in debugger technology to trigger a halt (or some actionable event) based on the access and content of a particular memory location. This access can be just a read or even a write of the same or a different value. In the case of a different value, this is a trigger on data change. Data breakpoints can also be called address breakpoints, since they trigger on an address access to examine the data.
There are typically two ways of implementing data breakpoint:
(A) Hardware support: typically in the form of on-chip address comparators linked to the exception mechanism. This is the most powerful and ideal solution for most cases.
(B) Software emulation: this is a usually very limited solution that can be used when no address comparators are available. The traditional method used for the data breakpoint software emulation is plagued with several major problems. Software data breakpoints generally only trigger on data change and are generally extremely slow. Software data breakpoints can only trigger after the access is done, not just before, unlike with address comparators. This occurs because software data breakpoints are based solely on single stepping every instruction and monitoring the change of value at the particular address pointed by the data breakpoint. An improvement in software-based data breakpoints is therefore desirable.